Add AUDIT_ARCH_* constants from linux/audit.h - #5311

Can you just use https://docs.rs/linux-raw-sys/latest/linux_raw_sys/ptrace/index.html? We're trying to slim down the number of kernel bindings libc has.

@tgross35 Thanks for the review and pointing me to linux-raw-sys::ptrace!

After looking at actual usage patterns in the ecosystem, I think there's still a case for keeping them in libc. Let me explain:

Key Points

1. libc already has the seccomp API

libc provides seccomp() syscall and 30 related constants:

• SECCOMP_MODE_*, SECCOMP_SET_MODE_*
• SECCOMP_RET_* (return values)
• SECCOMP_FILTER_FLAG_* (flags)

AUDIT_ARCH_* constants are used primarily for architecture validation in seccomp BPF filters they complete this API.

2. Production projects are hardcoding because they use libc, not linux-raw-sys

rust-vmm/seccompiler (used by Firecracker 35k stars):

src/backend/bpf.rs:119-129:

pub const AUDIT_ARCH_X86_64: u32 = 62 | 0x8000_0000 | 0x4000_0000;
pub const AUDIT_ARCH_AARCH64: u32 = 183 | 0x8000_0000 | 0x4000_0000;
pub const AUDIT_ARCH_RISCV64: u32 = 243 | 0x8000_0000 | 0x4000_0000;

Their dependencies (Cargo.toml):

• libc = "^0.2.153"
• No linux-raw-sys

youki container runtime (7.5k stars) same pattern: hardcodes values, uses libc.

3. Current ecosystem pattern

Projects using AUDIT_ARCH for seccomp (GitHub Code Search):

• rust-vmm/seccompiler → hardcodes, uses libc
• youki → hardcodes, uses libc
• 20+ other projects → similar pattern

The constants exist in linux-raw-sys::ptrace, but they're in the ptrace module while being used for seccomp filters. Projects doing seccomp work already depend on libc for the seccomp() syscall.

Question about libc's direction

I understand the goal to reduce kernel bindings in libc. I'd like to understand the criteria better so I can contribute more effectively in the future:

Should constants that are companions to existing libc APIs be included in libc?

For example:

• libc has seccomp() syscall + 30 SECCOMP_* constants
• AUDIT_ARCH_* constants are used primarily with seccomp BPF filters for architecture validation (seccomp(2) shows AUDIT_ARCH_X86_64 in example code, kernel docs emphasize "always check the arch value")
• They're part of the seccomp workflow, not general audit subsystem constants

Or is the policy to move all kernel-specific constants to linux-raw-sys regardless of their relationship to existing libc APIs?

Understanding this policy would help me (and projects like rust-vmm/seccompiler) make the right architectural decisions. If the direction is "use linux-raw-sys for kernel constants even when tied to libc APIs", that's valuable guidance for future contributions and I can help document that pattern.

What do you think?

☔ The latest upstream changes (possibly #5370) made this pull request unmergeable. Please resolve the merge conflicts.